-
Notifications
You must be signed in to change notification settings - Fork 51
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Replace internal dependencies by FetchContent #1583
Conversation
…ace library for nlohmann_json
This reverts commit 41a4658.
…D interface library for nlohmann_json" This reverts commit 6136a97.
This reverts commit 620d861.
Add the directory filled by FetchContent to .gitignore Add CMakeUserPresets.json to .gitignore
…ybind11 configuration.
for more information, see https://pre-commit.ci
.gitignore
Outdated
share/openPMD/thirdParty/json/ | ||
share/openPMD/thirdParty/toml11/ | ||
share/openPMD/thirdParty/catch2/ | ||
share/openPMD/thirdParty/pybind11/ |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
We should be aware that with this, the build folder will modify the source tree.
What does the workflow look like switching between different openPMD versions that specify different dependency versions. Will FetchContent notice and update the dependencies' versions upon configuring?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
That is true and might be a problem. I don't have experience with this.
Moving from lower to higher versions of OpenPMD should not be a problem. These directories have been deleted using git rm
and should therefore be deleted when moving forward. FetchContent can then download into these directories w/o problem.
A problem might arise if one moves from a higher to a lower version. If the directories have been populated by FetchContent and git tries to add the old libraries again in the same directories I can not predict the behavior.
It would be possible to use a different directory with FetchContent until we are sure that it works as expected.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Since @ax3l uses FetchContent in WarpX, let's wait until he is back to see what their approach looks like (relevant bits in their CMake config: https://github.com/ECP-WarpX/WarpX/blob/11e2a1722aac8929db0ed677f634673d235c1396/cmake/dependencies/openPMD.cmake#L29)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'll move this to the build directory, as we do in other project.
CMakeLists.txt
Outdated
toml11 | ||
GIT_REPOSITORY https://github.com/ToruNiina/toml11 | ||
# Migrate to the latest commit to remove CMake Warning which is not yet | ||
# available in any official release. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
You mean the warning below? Do I understand correctly that this has been fixed on toml11 dev and we are waiting for the next release?
CMake Deprecation Warning at share/openPMD/thirdParty/toml11/CMakeLists.txt:1 (cmake_minimum_required):
Compatibility with CMake < 3.5 will be removed from a future version of
CMake.
Update the VERSION argument <min> value or use a ...<max> suffix to tell
CMake that the project does not need compatibility with older versions.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yes.
But also moving to the last commit is not trivial with toml11 since that requires CMAKE_CXX_STANDARD
to be set which I could not add to openPMD-api w/o breaking the CI.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
since that requires
CMAKE_CXX_STANDARD
to be set which I could not add to openPMD-api w/o breaking the CI.
That's probably an issue unrelated to this PR which we should better solve separately?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yes, after finishing this PR I would try to Update catch2 and toml11 with separate issues as described above
Co-authored-by: Franz Pöschel <[email protected]>
Is it to be expected that one of the CI stages fails? The error in this step does not seem to be related to the changes of this pull request. |
The failure comes from the increased minimum CMake version:
The other "red text" seems to be unrelated (I see it on other PRs also), but does not cause a failure Is version 3.22 also fine as a minimum? Otherwise, I'll push a commit that tries bumping the minimum CMake version of that CI run. |
Yes, sorry I was confused by the first red section in that action. CMake 3.24 was the lowest version which still works with the implementation that I provided here. Using a lower CMake Version requires to remove the |
It seems like we need to consider saying good-bye to the Win32 CI runner. The last updates in https://repo.anaconda.com/pkgs/main/win-32/ were in 2022, the latest included CMake version is 3.22.1 from Dec 7, 2021, hence the failure. |
After an offline discussion, this might be the preferred way to go. Even if Win32 is end of life, the runners are still useful as they are a good way to check our handling of datatypes, also Win32 is still being used in lab settings. |
Revert previous commit to use cmake 3.22 in Win32 CI runner.
This reverts commit 5976cc9.
c2cf2c9
to
ea5b8db
Compare
I think the Appveyor part of our CI has no way to trigger a selective restart |
@ax3l is there any chance to get direct access to the system on which the CI is failing? That would be easier than debugging this error by additional commits to this pull request. |
I can reproduce the same error an a Linux system using CMake 3.22.1 |
The problem is that CMake 3.22 does not correctly interpret the |
We could also just depricate the |
638e6b4
to
9d402b5
Compare
580f5ff
to
289c872
Compare
Dependent projects might have the same dependencies and build as a superbuild as well.
289c872
to
cce18a8
Compare
Thanks a lot, @DerNils-git! I'll merge this and do a few follow-up PRs:
One thing I really miss in Alternatively, we could pull a tarball from the releases page of projects... #1668 |
Replace internal dependencies management by CMake FetchContent commands.
Advantage:
FetchContent_Declare
which makes it easier to stay at the project HEAD of dependencies for project maintainersRequired changes:
Dependencies still have to be updated:
CMAKE_CXX_STANDARD
to be set if the latest hash shall be usedIf the pull request is accepted I would open issues to update the dependencies mentioned above and assign them to me.
(Sorry about the slightly chaotic git history. The change to FetchContent is done from 0ba14dc to 0084e9b. The previous commits resulted from a previous try to move to FetchContent which failed and the commits are reverted)